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1. INTRODUCTION 

University of California, Berkeley and Stanford University developed a concept of centralized system 
to manage network devices on a network architecture as known as software defined network [1]. The concept of 
software defined network is by separating between data plane and control plane. The forwarding plane is remains 
on the network devices and a control plane is in a separate entity called controller [2-5]. By using 
the controller network administrator is allows to configure a software defined network infrastructure without 
direct configuration on physical devices. Software defined network has an ability to maximize the utilization of 
network devices, such as load balancing, traffic engineering, and other programmable stuff [2-5]. The first concept 
of OpenFlow first developed at Stanford University in 2008. OpenFlow is the first standard communication 
protocol between control plane and data plane on the SDN network architecture. Version 1.0 of OpenFlow was 
released in December 2009 [6-10]. OpenFlow is currently managed by Open Networking Foundation (ONF), and 
user-based organization dedicated to open standards of software defined network [11, 12]. Load balancing is 
a technique to distribute a traffic on two or more data paths in a balanced way, thus maximize the utility of each 
gateway [13-15]. Floodlight controller is an enterprise-class OpenFlow controller that 1s apache-based and 
Java-based, supported by big switch networks [16-18]. Mininet is an emulator that is used to emulate a network 
architecture on software defined network environment [19, 20]. 

In order to increase the network performance, it needs two or more data path to direct the traffic from 
source-destination. Load balancing is used to maximize the utility of each gateways in a network architecture. 
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Similiar work has been done, in [21, 22] authors used pox contoller, built the network with bipartite topology 
with random number of L1 between 1-4 and L2 between 1-8, but the created system had a limitation of 
recursive function. In [22] the authors used Floodlight Controller, but actually the built-in load balancer in 
Floodlight controller is used for server load balancing not for gateway load balancing or network redundancy. 
In this paper, we chose a Floodlight Controller and implemented load balancer to the controller, with the same 
topology is used, as shown in Figure 1 [23] with random number of gateways connected to switches in L2 (L1) 
between 2-4 and number of host-connected switches (L2) between 2-8. The evaluation is done by measuring 
QoS (delay, bit rate, packet rate, packet success rate) while sending various traffics through the network such 
as UDP flow, VoIP, and DNS. 


Li 





L2 


bh 


Figure 1. Bipartite topology 


2. RESEARCH METHOD 

We used programmable switches on mininet that support OpenFlow 1.3 as a standard communication 
protocol with a connected floodlight controller [24]. The IP address of the network devices in this network are 
stored in the controller, each switch on the network doesn’t have IP address on its own. Hosts on this system 
can be client, servers, and other end-user devices. IP address is given by the dynamic host configuration 
protocol (DHCP). DHCP is run by the controller. Switches on this system are work as a relay between the host 
and the controller. IP Address on this system only has one subnet. 

This research, implemented load balancing in software defined network architecture using floodlight 
controller. In order to run the load balancing, there are two main functions on the system, such as main system 
and supporting system. The main system is a system that run the main function, namely gateway load balancing, 
using Djikstra routing algorithm. The type of load balancing used is least-load-per-flow load balancing. Each 
flow is a combination of IP Address, MAC address and source-destination port [25]. Controller determine 
which gateway is compatible to forward matching packet from the flow. The chosen gateway is a gateway with 
the lowest traffic at the time. In order for the main system to run, needs support system that can run functions 
such as forwarding process, DHCP service, monitoring and proxy ARP. 

In this paper, we tested a load balancer function that implemented on Floodlight controller with 
bipartite topology. The number of gateway connected to switches in L2 (L1) between 2-4 and number of 
host-connected switches (L2) between 2-8. Several types of traffic, including UDP flow, VoIP, and DNS is 
sent through the network while delay, bit rate, packet rate and packet success rate of each traffic is measured. 
For the evaluation we used 2 scenarios as shown in Table 1, such as scenario 1 and scenario 2. 


Table 1. Evaluation scenario 


LI L2 Number of Host Generate Value of Background 
Background Traffic Traffic 

Scenario | 2 2-8 2343638385838 100 Mbit/s 

3 2-8 2;4;6;8;8;8;7 100 Mbit/s 

4 2-8 2;4;6;8;8;7;7 100 Mbit/s 
Scenario 2 2 2-8 4 100 Mbit/s 

3 2-8 4 100 Mbit/s 

4 2-8 4 100 Mbit/s 


3. RESULTS AND DISCUSSION 

The evaluation is done by measuring delay, bit rate, packet rate and packet success rate in a bipartite 
topology with different combination of L1 and L2 while sending various types of traffic with two different 
evaluation scenarios, such as: 


3.1. Scenario 1 
3.1.1. UDP flows 

Figure 2 shown the value of delay decreased compared to results before load balancing. The more 
number of switches connected to the host, the value of delay is increased due to the more number of host that 
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generates the background traffic in each topology. Figure 3 shown the value of bit rate. The decreased value 
of delay after load balancing can increased the value of bit rate. Figure 4 shown the value of packet rate. 
The decreased value of delay after load balancing can increased the value of packet rate. Figure 5 shown 
the value of packet success rate. Based on the Figure 5 there are obtained a packet loss but the load balancer 
can reduce the value of packet loss. 


—@— Before Load Balancing (ms) L1 = 2 fi After Load Balancing (ms) 
ie Before Load Balancing (ms) L1 = 3 After Load Balancing (ms) 
= Before Load Balancing (ms) L1 = 4 =@= After Load Balancing (ms) 
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Figure 2. UDP flow delay 
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Figure 5. UDP flow packet success rate 
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3.1.2. VoIP 

Figure 6 shown the value of delay decreased compared to results before load balancing. The more 
number of switches connected to the host, the value of delay is increased due to the more number of host that 
generates the background traffic in each topology. Figure 7 shown the value of bit rate. The decreased value 
of delay after load balancing can increased the value of bit rate. Figure 8 shown the value of packet rate. 
The decreased value of delay after load balancing can increased the value of packet rate. Figure 9 shown 
the value of packet success rate. Based on the Figure 9 there are obtained a packet loss but the load balancer 
can reduce the value of packet loss. 
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Figure 6. VoIP delay 
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Figure 9. VoIP packet success rate 
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3.1.3. DNS 


Figure 10 shown the value of delay decreased compared to results before load balancing. The more 
number of switches connected to the host, the value of delay is increased due to the more number of host that 
generates the background traffic in each topology. Figure 11 shown the value of bit rate. The decreased value 
of delay after load balancing can increased the value of bit rate. Figure 12 shown the value of packet rate. 
The decreased value of delay after load balancing can increased the value of packet rate. Figure 13 shown 
the value of packet success rate. Based on the Figure 13 there are obtained a packet loss but the load balancer 
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can reduce the value of packet loss. 
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Figure 13. DNS packet success rate 
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From all results above for scenario 1, we can conclude that Load balancer performance is work well 
and can handle all types of traffics. The results after load balancing is better than before load balancing. 
But, adding the number of gateways, doesn’t increased the performance of the network. Since the value of 
delay at L1 = 2 is better than L1 = 3 and L1 = 4. 


3.2. Scenario 2 
3.2.1. UDP flows 

Figure 14 shown the value of delay decreased compared to results before load balancing. Although 
the number of host that generates background traffic 1s same, the more number of switches-connected to host 
increased the value of delay. It cause using the Djikstra routing algorithm, it takes time to find the path and 
calculate the link cost of each path. Figure 15 shown the value of bit rate. The decreased value of delay after 
load balancing can increased the value of bit rate. Figure 16 shown the value of packet rate. The decreased 
value of delay after load balancing can increased the value of packet rate. Figure 17 shown the value of packet 
success rate. Based on the Figure 17 there are obtained a packet loss but the load balancer can reduce the value 
of packet loss. 
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Figure 14. UDP flow delay 
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Figure 15. UDP flow bit rate 
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Figure 16. UDP flow packet rate 
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Figure 17. UDP flow packet success rate 


3.2.2. VoIP 

Figure 18 shown the value of delay decreased compared to results before load balancing. Although 
the number of host that generates background traffic is same, the more number of switches-connected to host 
increased the value of delay. It cause using the Djikstra routing algorithm, it takes time to find the path and 
calculate the link cost of each path. Figure 19 shown the value of bit rate. The decreased value of delay after 
load balancing can increased the value of bit rate. Figure 20 shown the value of packet rate. The decreased 
value of delay after load balancing can increased the value of packet rate. Figure 21 shown the value of packet 
success rate. Based on the Figure 21 there are obtained a packet loss but the load balancer can reduce the value 
of packet loss. 
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Figure 18. VoIP delay 
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Figure 19. VoIP bit rate 
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Figure 20. VoIP packet rate 
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Figure 21. VoIP packet success rate 


3.2.3. DNS 

Figure 22 shown the value of delay decreased compared to results before load balancing. Although 
the number of host that generates background traffic 1s same, the more number of switches-connected to host 
increased the value of delay. It cause using the Djikstra routing algorithm, it takes time to find the path and 
calculate the link cost of each path. Figure 23 shown the value of bit rate. The decreased value of delay after 
load balancing can increased the value of bit rate. Figure 24 shown the value of packet rate. The decreased 
value of delay after load balancing can increased the value of packet rate. Figure 25 shown the value of packet 
success rate. Based on the Figure 25 there are obtained a packet loss but the load balancer can reduce the value 
of packet loss. 

From all results from scenario 2, we can conclude that load balancer performance is work well and 
can handle all types of traffics. The results after load balancing is better than before load balancing. Although 
the number of the host that generates background traffic is same, the more number of switches connected to 
the host increased the value of delay because using the djikstra algorithm it takes time to find the path and 
calculate the link cost of each path. But, adding the number of gateways, doesn’t increased the performance of 
the network. Since the value of delay at L1 = 2 is better than L1 = 3 and L1 = 4. 
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Figure 22. DNS delay 
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Figure 23. DNS bit rate 
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Figure 24. DNS packet rate 
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Figure 25. DNS packet success rate 


4. CONCLUSION 

The purpose of this study is to understand the effects of load balancing on SDN using a floodlight controller. 
Separating control fields from data fields on SDN creates different architectural settings so that our experiment is to 
get the best settings. In this paper, we perform two load balancing functions, namely the main system and the support 
system. The main system is a system that performs the main function, namely Gateway Load Balancing using 
the Dyikstra routing algorithm. The type of load balancing used is load balancing with a minimum load. This study 
was designed to measure the effects of bipartite topology with two scenarios. The first scenario 1s adding the number 
of gateways and the second scenario adding the number of hosts that generate background traffic. We evaluate that 
increasing the number of gateways to Qos performance on UDP, VoIP and DNS services is not large. We, therefore, 
conclude that load balancing with SDN can be applied to the maximum even though the number of gateways is 
added as the number of hosts passes through the network. The results of this analysis revealed that SDN is ready to 
be applied to large networks but still must pay attention to the QoS requirements of realtime services such as VoIP 
because the number of gateways makes a slight increase in delay. Further work needs to be done to determine 
whether there are different effects when we use other algorithms and different topologies using multiple gateways. 
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